CONTENT-BASED BILLING SERVICE 
FOR WIRELESS PREPAID SUBSCRIBERS 

Field of the Invention 

The present invention relates to content-based billing services, and more 
specifically to methods of providing content-based billing services for prepaid 
wireless subscribers. 

Background of the Invention 

As will be appreciated by those skilled in the art, the wireless or mobile 
telephone is no longer simply used for voice communications. Although voice 
communications remain a primary purpose for many of these communication 
devices, these devices are being called on to provide the same communication 
data exchange services demanded by the hard wired communication systems 
including the transmission of vast amounts of data such as provided through 
public and private internet connections. However, there exists a substantial 
infrastructure in place for wireless communication systems. Therefore, the 
additional challenges of compatibility and incorporation of the existing 
infrastructure is required while still providing the new services at a reasonable 
and competitive cost. 

Data provided through the internet is available under many different 
conditions. Some data is free, and other data is provided at different costs and 
rates. In addition, communication service providers often provide subscription 
programs with various incentives and variable charges per data bit. Further, for a 
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given service provider, these charges may change as a function of call volume, 
subscriber location, time of day, and the like. Therefore, to be cost competitive, 
the wireless service provider should be able to also provide such variable rates. 

To accomplish this, recent wireless communications have evolved from 
the original analog cellular or mobile telephones which used TDMA (Time 
Division Multiple Access) and was almost entirely limited to voice 
communications. TDMA was also used with second-generation digital mobile 
cellular phones that transmitted voice data in digital packets. Transmission by 
digital packets, however, readily lends itself to the transmission or exchange of 
vast amounts of non-voice data as well as voice data. In fact, because of the 
requirements that voice data must be provided at regular and precise intervals if 
it is to be understood, voice data presents some challenges not present with 
ordinary or non-voice digital data. In any event, the demands for transmitting 
various types of digital data has recently exploded, and the processing or 
packaging of non-voice digital data for transmission over wireless communication 
systems has developed separately from the processing and packaging of voice 
data packets. Consequently, the two types of data packets are processed 
separately and then merged and transmitted over both the second-generation 
TDMA systems and third generation CDMA (Code Division Multiplex Access) 
type systems. It should also be noted that CDMA is also used in 2G cellular 
networks like Sprint PCS and Verizon. It is not required that 3G systems use 
CDMA, but systems presently being developed are using CDMA. 
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Summary of the Invention 

Other objects and advantages of the invention will in part be obvious, and 
will in part appear hereinafter, and will be accomplished by the present invention 
which provides methods of providing content-based billing to a prepaid 
subscriber. The steps of the method according to this invention comprise 
initiating contact between a first SGSN (Serving General Packet Radio Service 
Support Node) and an SCP (Server Control Point) regarding the account profile 
of a prepaid subscriber. The SCP then provides volume limit threshold data to 
the first SGSN. The volume limit threshold data is then forwarded from the 
SGSN to a GGSN (Gateway GPRS Support Node). Data packets are then 
exchanged between the BSC (Base Station Controller) or Radio Network 
Controller (RNC) and the SGSN in the usual manner as is known by those skilled 
in the art. However, the billable data count is accumulated at the GGSN 
according to the specific profile of the prepaid subscriber. According to one 
embodiment of the invention, and dependent upon the prepaid subscriber 
account profile, the GGSN will not accumulate a billable data count for data 
designated as non-billable or "free" data. According to other embodiments, the 
GGSN may accumulate different types of data at different billing data counts or 
rates. That is, some types of data may accumulate a data count at a standard 
rate, whereas other types of data may accumulate at a higher or lesser data 
count than the standard rate. 

The total data count will then be provided to the SGSN whenever the data 
exchange between the SGSN and a specific BSC is interrupted. Such an 
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interruption may occur as a result of the call being terminated either voluntarily or 
in the event of an equipment failure, or when the mobile phone involved with the 
call moves from one regional area to a new regional area. The total data count 
will also be transmitted from the GGSN to the SGSN when the accumulated total 
data count reaches the volume limit threshold set by the SCP. This accumulated 
data count is then forwarded from the SGSN to the SCP, which then, in the event 
of the volume limit threshold being reached will either increase the volume limit 
data threshold count and allow the data exchange to continue, or the SCP will 
instruct the SGSN to terminate the data exchange. If the call is terminated 
before the volume limit threshold is reached, the SCP will adjust the overall 
volume limit threshold available for a subsequent call or data exchange. 

In the event the mobile phone is moving from one region to another, the 
original SGSN will be contacted by a new or second SGSN to allow an 
uninterrupted "hand off' of the call. The new SGSN will also contact the SCP for 
the prepaid subscriber profile and information, and the GGSN providing the 
internet data. The new SGSN will then continue the data exchange process in 
the same manner as discussed above. 

Brief Description of the Drawings 

Figure 1 illustrates a communication set up according to Figure 1 and 
further includes providing for content-based billing to prepaid subscribers. 

Figures 2a, 2b, 2c, 2d and 2e illustrate the prior art signal exchanges for 
establishing communication channel scheme without content-based billing. 
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Figures 3a, 3b, 3c, 3d and 3e illustrate the signal exchanges for 
establishing a communication scheme, which includes content-based billing of 
prepaid subscribers according to the teachings of the present invention. 

Figure 4 illustrates an alternate embodiment for providing down-link 
content-based billing for prepaid subscribers using the prior art signal exchanges 
of Figures 2a, 2b and 2c, but designating a data bit in the down link data frame 
header as billable or not billable. 

Description of Preferred Embodiments 

Referring now to Figure 1 , there is shown a functional schematic diagram 
incorporating the features of the present invention. It will be appreciated that 
although certain of the functions indicated in the figure, are separated from other 
functions. Such separation is not intended to suggest that the hardware 
providing these functions will also be separated. For example, the GGSN 
(Gateway GPRS Support Node) and the SGSN (Serving GPRS Support Node) 
may be incorporated as a single piece of hardware or co-located at a single 
location. 

Although details of the signal flow will be discussed hereinafter, a 
generalized discussion of the functional diagram follows. As shown, a wireless 
terminal 10 is in communication with a transmission tower 12 in a particular 
region or area. As used herein, the term "wireless terminal" is applicable to 
wireless/mobile telephones, terminals in the form of combinations of wireless 
Personal Digital Assistants (PDAs or "Palm Pilots") and mobile telephones, 
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wireless networking cards connected to stationary or mobile equipment, and the 
like. The transmission tower 12 is itself in communications with a controller 14 
such as a BSC (Base Station Controller) or Radio Network Controller (RNC) 
which receives and combines both voice packets indicated at 16 and data 
packets provided by signal 18 from a first support node such as a Serving GPRS 
Support Node (SGSN) 20 available from the Nortel Networks. The SGSN is itself 
in communication with a Gateway GPRS Support Node (GGSN) 22 which 
provides the gateway to the internet services which will include normal internet 
data service, provider data, and private internet data as indicated at 24. It is also 
noted that the GGSN 22 may also be in communication with other SGSNs such 
as a second SGSN 26. Although Figure 1 indicates two SGSNs in 
communication with a single GGSN, it will be appreciated by those skilled in the 
art that GGSN 22 may in fact be in contact with a large number of SGSNs. 
Likewise, although one GGSN 22 is shown as being in contact with SGSN 20 
and SGSN 26, it will be appreciated that each SGSN may be in contact with a 
number of GGSNs. It should also be noted that SGSN 20 is also in contact with 
CGF (Charging Gateway Function) as is SGSN 26. Likewise, both SGSN 20 and 
SGSN 26 are in communication with a service control point such as SCP 30 
shown in Figure 1 . 

Figure 1 includes a second SGSN 26 for purposes of illustrating how 
wireless terminal 10 may be in the form of a mobile terminal capable of 
movement from the first location where it is in radio communication with 
transmitting tower 12 to a second location as indicated at 10a where it is in 
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communication with a second transmission tower 32 located in a different region. 
Likewise, tower 32 is in communication with a second controller BSC/RNC 24 
that, in turn, is in communication with a second TDM voice packet controller 36, 
and as discussed, is in communication with SGSN 26 for exchanging data 
packets other than voice data packets. 

As will be appreciated, non-voice digital packets typically originate from 
the public internet, internet service providers or private internet systems as 
indicated by internet "cloud" 24 in Figure 1 . As will also be appreciated by those 
skilled in the art, much of the data available from the internet cloud 24 can be 
provided at no cost, whereas much of the other types of data may be provided at 
varying costs including minimal costs or in some cases a very high cost. Thus, if 
the wireless communications service provider is to provide such data to the user, 
there must be a way to charge for the non-free data. Thus, the gateway GPSR 
support node (GGSN) 22 is provided to keep track of the non-free internet data 
and provides the chargeable information to the CGF 28. The GGSN 22 also 
keeps track of the total amount of data bits provided and transmitted to SGSN 
20. The SGSN 20, on the other hand, according to the prior art, was used to also 
keep track of the amount of data bits exchanged with the hand held unit 10. 
Further, since most wireless systems charge on the basis of the number of data 
bits or data bit packages transmitted in either direction, the data bit counts 
accumulated by SGSN 20 provided this information to the SCP 30 for control and 
accounting purposes. This prior art system works reasonably well so long as the 
SGSN 20 can charge the same rate for all data passing between SGSN 20 and 
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the hand held unit 10. Thus, the SCP can determine the cost and the amount of 
time used by the wireless handheld unit, whereas the CGF can keep track of the 
internet data transmissions that are not free. This of course requires separate 
billings. However, for advertising and various marketing and sales techniques, 
most wireless providers prefer to control the billing and therefore offer 
subscribers a number of prepaid minutes and would like to be able to offer a 
portion of the free internet data at no charge to the customer. Further, it also 
would be desirable to be able to provide accumulated charge data counts at 
different rates depending upon the cost of the data bits from the internet source 
24. Thus, the present invention, although using substantially the same functional 
equipment available for present communication connections between handheld 
units and the internet, provides the opportunity for such content-based billing to 
prepaid subscribers. 

Referring now to Figures 2a, 2b, 2c, 2d and 2e, there is shown a signal 
flow diagram typically used in a prior art system for charging a pre-paid customer 
according to the number of data bits exchanged. Figures 3a, 3b, 3c, 3d and 3e 
are substantially similar to those Figures 2a - 2e except they include the novel 
features of this invention used for content-based billing to prepaid subscribers. 
As shown in Figure 2a, a base station controller such as BSC 14 receives a 
request or communication indicating a need for packet data from a packet data 
provider as indicated by signal 40. Although the wireless terminal 10 may also 
be used for the transmission of voice packets such as for normal telephone 
communications, the remaining discussion will be with respect to the 
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communication of data other than voice packets. SGSN 20 will receive the 
request for packet data from a particular provider and will in turn contact the SCP 
30 to determine if the subscriber is authorized to connect to the internet. 
Although the handshaking process between the SGSN 20 and SCP 30 actually 
comprises more than one communication, this process is well known to those 
skilled in the art and therefore, signal 42 represents all of the different 
communications necessary. Thus, it is seen that the initial signals from the 
SGSN 20 to SCP 30 not only establish contact with the packet data provider, but 
also provide the requesting information to the SCP, which is then compared to 
the subscriber's profile to determine what services are available to a particular 
subscriber. Once the SCP 30 evaluates the subscriber's profile, necessary 
information and instructions including the volume limit threshold data is 
transmitted back from the SCP 30 to SGSN 20 by signal 44. It should be noted 
at this point, that for a specific prepaid subscriber, the SCP 30 simply relays back 
the volume limit threshold, which represents the total number of data bits prepaid 
by the subscriber. SCP 30 will then provide instructions to continue with the 
GPRS data exchange as indicated by signal 48. At this point, it should be noted 
that there have been no instructions or data exchange signals between SGSN 20 
and GGSN 22 for these initial contact procedures or signaling procedures used 
by the prior art. 

Signals representing functions, which are common to both the prior art 
initiation procedure of Figure 2a and the new procedure of this invention as 
shown in Figure 3a, will carry the same reference numbers. Therefore, as shown 
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in Figure 3a, and as was the case with respect to the prior art, the BSC 14 
requires the activation of a packet data provider communication set up as 
indicated by signal 40. Also as was the case with respect to the prior art, this 
data is provided from the SGSN 20 to SCP 30 as indicated by signal 42. Then 
as indicated by signal 44, SCP 30 provides the necessary instructions and 
information (including volume limit threshold data) to SGSN 20. As discussed 
above, the SCP may provide different instructions to the SGSN depending on the 
subscriber profile. For example, in addition to providing the volume limit 
threshold in the event of a paid up and current account, the SCP 30 may instead 
instruct SGSN 20 to terminate or disconnect the PDP [Packet Data Protocol ] 
Context request if the customer profile indicates the account is in arrears or has 
not authorized such information or data to be provided. However, in the event of 
a current account, the volume limit threshold data will be provided to the SGSN 
20 as discussed above. Unlike the prior art sequence of signals as discussed 
with respect to Figure 2a, according to the present invention, once the SGSN 20 
receives the instructions or data from SCP 30, the volume limit threshold data 
information is forwarded to the GGSN 22, as indicated by signal 50. Upon 
receiving the volume limit threshold data from the SGSN 20, GGSN 22 will then 
acknowledge this information and sends an acknowledging signal as shown on 
signal 52 to SGSN 20. SGSN 20 then send an acknowledgment of receipt of the 
data from SCP 30 and also transmits the fact the volume limit threshold data was 
successfully forwarded to GGSN on signal 46 back to SCP 30. Then, as was the 
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case with respect to the prior art, SCP 30 instructs the SGSN 20 to continue as 
indicated by signal 48. 

Referring now to Figure 2b, there is illustrated the prior art data exchange 
and control signal flow. As shown, upon receiving the instruction to continue the 
GPRS data exchange on signal 48 from the SCP 30, as was illustrated in Figure 
2a, there is then an ongoing data transfer in both directions as indicated by the 
double-headed arrow 54. According to the prior art, both the GGSN 22 and the 
SGSN 20 simply monitored the total number of data bits passing there between. 
Since all data bits were counted by both the GGSN 22 and the SGSN 20, these 
numbers should agree according to the prior art procedure. Therefore, once the 
SGSN 20 data count reaches (or is equal to) the volume limit threshold as 
instructed by SCP 30, SGSN 20 provides a signal to SCP 30 indicating the 
volume limit threshold count has been reached. In addition, both the SGSN 20 
and the GGSN 20 provide the data count to the CGF 28. Thus, there is 
verification of the data count accuracy. The signal from SGSN 20 to SCP 30 
indicating that the volume limit threshold has been reached is indicated by signal 
56. SCP 30 then acknowledges receipt of the information on the return signal 58 
and begins evaluating the subscriber's profile. Upon completing the evaluation of 
the subscriber's accounting profile, SCP 30 then instructs the SGSN 20 to either 
terminate the PDP data exchange as indicated by signal 60, or alternately and 
assuming a favorable accounting record history, the SGSN 20 instead of 
instructing termination of the PDP data exchange may send a modified volume 
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limit threshold value to the SGSN 20. This signal to modify the volume limit 
threshold is indicated at signal 62. 

Referring now to Figure 3b, there is shown a signal flow diagram similar to 
that of the prior art Figure 2b, except this diagram includes modifications 
according to the present invention. Again, as was the case with Figures 2a and 
3a, signal flow, which is the same for the prior art and the present invention carry 
the same reference numbers. Thus, as shown, and as was the case in the prior 
art, the ongoing data transfer occurs as indicated by signal 54. However, unlike 
the prior art, it will be recalled that the GGSN 22 now also possesses the 
information related to the volume limit threshold representing the number of data 
bits prepaid and allowed to be transferred between the SGSN and the GGSN 
without further charge. Thus, it should be appreciated that for data bit exchange 
indicated as being free according to the prepaid subscriber's profile, the GGSN 
22 will accumulate data at a slower and lesser rate than the SGSN 20. Thus, 
according to this embodiment of the invention, The SGSN 20 will not report that 
the volume limit threshold number of data bits has been reached to SCP 30 until 
instructed to do so by the GGSN 22 no matter what its own count of the data bits. 
Thus, only when GGSN 22 also has a data count which indicates that the volume 
limit threshold has been reached, will GGSN 22 send this information to SGSN 
20 as indicated by signal 66. SGSN 20 will then acknowledge receipt of this 
information as indicated by signal 68. SGSN 20 will also send a signal 56 
indicating that the volume threshold limit has been reached or exceeded as was 
done in the prior art and discussed with respect to Figure 2b. The signal flow for 
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this invention from this point is the same signal flow as the prior art except that 
once the SCP 30 has provided a new volume limit threshold limit to SGSN 20 to 
allow continuing of the GPRS data exchange as indicated by signal 62, SGSN 20 
then forwards this new volume limit threshold information to GGSN 22 as 
indicated by signal 70. Receipt of this new volume limit threshold information is 
then acknowledged by the GGSN as indicated in signal 72. 

As was mentioned earlier, the subscriber receiving the internet data 
exchange will normally complete such a data exchange before the prepaid 
number of data bits or the threshold volume limit is reached. Thus, this 
subscriber will simply hang up or otherwise deactivate the data exchange with 
the internet. Therefore, referring now to Figure 2c such deactivation is indicated 
by the deactivation signal 74 from the BSC 14 to the SGSN 20. According to the 
prior art, upon receiving a notice of deactivation on signal 74, the SGSN 20 
simply provided the data bit volume count to SCP 30 as indicated by signal 76. It 
will be appreciated that this was quite acceptable according to the prior art since 
the data bit count in the SGSN 20 and the GGSN 22 were the same. Then 
according to the prior art, the SCP 30 would simply respond with an 
acknowledgment that the billing count had been received as indicated by signal 
78. After the acknowledgment by SCP 30 by signal 78, the final handshaking 
and disconnect procedure as indicated by signals 80, 82, 84, 86 and 88 in Figure 
2c would then take place to complete the disconnect and delete the PDP 
connections. The signal flow according to the present invention, as was the case 
in the previous two examples, illustrated in Figures 3a and 3b, for such a packet 
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data provider deactivation has some similarity to the prior art and therefore 
includes many of the same signals. However, it will be recalled that according to 
the invention the data count for GGSN 22 will be lower than the data count for 
SGSN 20 in the event free (no charge) data was being transmitted between 
GGSN 22 and SGSN 20. Consequently, rather than simply sending the data 
count from SGSN 20 directly to SCP 30, SGSN 20 must first request or retrieve 
the accumulated billable traffic count from GGSN 22 as indicated by signal 90. 
GGSN 22 then provides this reduced data count representing a data count which 
does not include the free data to SGSN 20 as indicated by signal 92. This 
revised data count is then provided to the SCP 30 from SGSN 20 as indicated by 
the signal 76A. It should be appreciated that the information provided by signal 
76 in Figure 2a of the prior art, and signal 76A in Figure 3a according to the 
present invention would likely be different since, the SCP 30 only receives a 
chargeable data count and is not concerned with the fact that the data count is 
only for some of the data bit and may not contain a complete data count. Thus, 
there has been described to this point a typical scenario between initiation of a 
PDP connection followed by a normal deactivation in a situation where the 
volume limit threshold was exceeded and a new volume limit threshold 
determined. 

However, it will also be appreciated by those skilled in the art as was 
indicated in Figure 1 , that wireless telephones and communication devices are 
most effective as a mobile system. Therefore, as often happens, the wireless 
terminal 10 may be in the form of a mobile terminal capable of movement beyond 
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the transmission limits of tower 12 and the corresponding BSC 14, and therefore, 
if data exchange is to continue, it must be picked up by a different BSC/RNC 24 
and transmitting tower 32. Therefore, referring now to Figures 2d and 2e, there 
is illustrated an example of the prior art control signal flow which provides for a 
"hand off' between the control tower 12 and BSC/RNC 14 to the control tower 32 
and BSC/RNC 24. This signal flow is indicated by signals 94 through 1 16 in 
Figure 2d, and signals 118 through 132 in Figure 2e. Since each signal indicates 
its purpose and is similar to that discussed with the previous figures, these 
figures will be discussed generally and in less detail than the previous figures. 
For example, referring to Figure 2d and as will be appreciated by those skilled 
the art, before handset 10 moves beyond the transmission limits of tower 10, 
transmissions from handset 10 are picked up by tower 32 and BSC/RNC 24 in 
the same manner as the BSC/RNC 14. At some signal level threshold, another 
or second SGSN 26 will see this signal transmission as a connection request as 
indicated by signal 94. At this point, SGSN 26 will set up a handshake procedure 
with the old or first SGSN 20 as indicated by signals 96, 98 and 100 indicating to 
SGSN 20 that it will be taking charge of the communication. Once SGSN 26 
sends an acknowledgment (signal 100) to SGSN20, SGSN 26 will then modify 
the existing PDP Context by notifying the GGSN that SGSN 26 is now serving 
this PDP Context as indicated by signals 102 and 104. As soon as the GGSN 22 
has indicated that the request has been received, BSC 34 will accept the hand 
off as indicated by signal 106 and then contact SCP 30 as indicated by signal 
108 in the same manner as the first SGSN 20 contact and the SCP30 when 
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making the initial connection. SCP 30 will then provide the appropriate 
instructions to the second SGSN 26, which may include a first option of 
instructing SGSN 26 to disconnect, as indicated by signal 1 12. That is, the data 
exchange connection is not appropriate or authorized with the new gateway 34. 

Alternately, SCP30 will provide the necessary charging information to the 
SGSN 26 as indicated by signal 1 14, and indicate that the data transfer should 
continue as indicated by signal 116. At this point in the same manner as 
occurred between the first SGSN 20 and GGSN 22, the second SGSN 26 will 
send the necessary billing information including the new volume limit threshold 
for non-chargeable data as indicated by signal 128 to GGSN 22. GGSN 22 will 
then respond that it has received this information as indicated by signal 136. 

Referring now to Figures 2e and 3e, there is shown the handshake 
release or pass off of the first SGSN 20 to the second SGSN 26. As shown, 
signals 96, 98 and 100 are the same signals as in the prior art Figure 2d. 
However, after the second SGSN 26 has acknowledged the contact as indicated 
by signal 100, according to the prior art technique, SGSN 20 provided SCP 30 
with the appropriate accumulated billing volume count as indicated by signal 118. 
As discussed above, since the SGSN 20 and the GGSN 22, according to the 
prior art procedure, should have identical data count, the report as indicated by 
signal 118 could be provided immediately. Signals 120 through 126 illustrate the 
prior art appropriate acknowledgment, disconnects, etc. as determined by the 
demands of the system. However, as shown in Figure 3e, after the second 
SGSN 26 acknowledges contact with the first SGSN 20, SGSN 20, according to 
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the present invention, requested the volume data count from GGSN 22 as 
indicated by signal 132. This information is then provided from GGSN 22 to 
SGSN 20 as indicated by signal 134, and then this amount is provided from the 
first SGSN 20 to SCP 30 by signal 118. 

Thus, there has now also been discussed appropriate signal flow 
according to the teachings of this invention for allowing the hand off of a wireless 
handset from one SGSN to a new SGSN. 

Another embodiment of the present invention, which enables a modified 
version of content-based billing for prepaid subscribers, is discussed with respect 
to Figure 4. The embodiment shown in Figure 4 is simpler than the previously 
discussed embodiment in that it eliminates the need for any additional signaling 
by using private or proprietary extensions between the GGSN and the SGSN. 
The traffic volume control and thresholds monitoring in the SGSN is also the 
same as was discussed with respect to the prior art. According to this 
embodiment, and referring to Figure 4, an unused bit of the GTP-U header on a 
data packet, such as spare bit 4 shown in the figure, at reference under 136 will 
be set to a 1 for non-billable packets of data. One is selected since zero is the 
normal default condition and will continue to indicate a billable packet data unit. 
However, it is to be appreciated that only down link traffic can be classified as 
billable versus non-billable, and all up link traffic will be recorded as billable. This 
characteristic notwithstanding, this approach may be desirable for a multitude of 
situations in view of its simplicity in deployment and management. 
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Thus, there has to this point been described the unique methods of this 
invention for providing content-based billing for use with prepaid subscribers. 
However, although the present application has been described with respect to 
specific methods, it is not intended that such specific references be considered 
limitations upon the scope of the invention except as is set forth in the following 
claims. 
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